In conventional communication systems, devices communicate with each other over a communication network, such as a local area network (LAN), the Internet or other wide area network (WAN), a wireless communication network, and/or a combination thereof. A device that is sending information is often referred to as a source (or “sending”) device, and a target recipient of the information is often referred to as a destination (or “receiving”) device. Of course, during the course of a communication session, the roles of each device may change from time to time. That is, each device may be both a source device at certain times and a destination device at other times. Indeed, in many types of communications each device may be simultaneously assuming both roles of source and destination, such as when performing real-time interactive communication. The source and destination devices may be any type of device capable of communicating information over a communication network in the manner described herein, non-limiting examples of which include personal computers, laptop or notebook computers, mobile computing devices, personal data assistants (PDAs), mobile telephones, and other processor-based communication devices.
Information is often communicated via an Internet Protocol (IP) datagram, which basically includes an IP header and some sort of message or “payload” information to be communicated. A given IP datagram is typically directed to one point of destination from the source device. The IP datagrams are passed through routers and/or other network devices within the communication network for delivery from the source device to the destination device.
As used herein, IP Datagram refers to those datagrams as described in the glossary of RFC 1812 (Requirements for IP Version 4 Routers). In general, an IP Datagram is the unit of end-to-end transmission in the Internet Protocol. An IP Datagram includes an IP header followed by a message (e.g., higher-layer data, such as TCP, UDP, ICMP, and the like). An IP Datagram is composed of one or more IP Fragments.
So, conventionally a source device possesses some information that it wants to communicate to a target destination device. One way of sending that information across the network is via data packets, where the information is broken into smaller packets (or IP datagrams) that are communicated across the network to the destination device. The packets are then received at the destination and reassembled back into the original information.
The Internet Protocol Suite, commonly referred to as TCP/IP, is often used for communicating packets over the Internet and other similar communication networks. Transmission Control Protocol (TCP) is one of the two original components of the suite, complementing the Internet Protocol (IP). TCP provides the service of exchanging data directly between a source device and a destination device on the same network, whereas IP handles addressing and routing messages across one or more networks. In particular, TCP generally provides reliable, ordered delivery of a stream of bytes from a program on a source device (e.g., a first computer) to another program on a destination device (e.g., another computer). In TCP, if a particular message is malformed or does not reach the destination device, then a request might be made to have the source device resend the packet.
TCP is the protocol that many major Internet applications, such as the World Wide Web, e-mail, and file transfer, commonly employ. Other applications, which do not require reliable data stream service (or which are willing to tolerate less reliability in favor of reduced latency), may use the User Datagram Protocol (UDP), which is another member of the Internet Protocol Suite and which provides a datagram service that emphasizes reduced latency over reliability. With UDP, computer applications can send messages, often referred to as datagrams, to other hosts on an IP network without requiring prior communications to set up special transmission channels or data paths.
UDP uses a simple transmission model without implicit hand-shaking dialogues for providing reliability, ordering, or data integrity. Thus, UDP natively provides an unreliable service and datagrams may arrive out of order, appear duplicated, or go missing without notice. UDP assumes that error checking and correction is either not necessary or performed in the application, avoiding the overhead of such processing at the network interface level. Time-sensitive applications often use UDP because dropping packets is preferable to waiting for delayed packets, which may not be an option in a real-time system. If error correction facilities are needed at the network interface level, an application may use the TCP or Stream Control Transmission Protocol (SCTP), which are designed for this purpose.
UDP's stateless nature is also useful for servers answering small queries from huge numbers of clients. Unlike TCP, UDP is compatible with packet broadcast (sending to all on local network) and multicasting (send to all subscribers). Common network applications that use UDP include the Domain Name System (DNS), streaming media applications such as IPTV, Voice over IP (VoIP), Trivial File Transfer Protocol (TFTP), and many online games.
Thus, in many types of communication sessions, such as employed in various multiparty interactive applications, the packets are communicated in a streaming or real-time fashion. For instance, the destination may receive packets that are being streamed and begin outputting the information contained in the received packets while further packets are in route to the destination device. For instance, in many multi-media applications, such as live voice and/or video communication between parties (e.g., videoconferencing, etc.), additional packets are being created at a source device as the destination device is receiving and starting to play previously-received packets.
Particularly with the development and proliferation of the Internet technology and broadband networks, there are increasing numbers of multiparty interactive applications available on the market. Multiparty interactive applications typically enable multiple users to interact in real time. Examples of these applications include, without limitation, videoconferencing, interactive gaming (e.g., Internet gaming), distance learning, and the like. Multiparty interactive applications conventionally employ a communication mechanism in the network layer to manage the transmission of packets between the applications. Typically, only one type of transport protocol is used. For example, a multiparty interactive application may send packets to other applications using TCP mechanisms. As mentioned above, TCP is a reliable protocol for controlled message delivery and requires separate connections for each source-destination pair.
The use of UDP may be a quicker way for multiparty interactive applications to send packets to other applications. However, UDP is connectionless and provides very few error recovery services. Thus, UDP is conventionally viewed as an undesirable transmission mechanism where reliability is a significant requirement or desire.
Multiparty interactive applications may also employ IP multicast to handle data transmission. IP multicast is a method whereby a message can be sent simultaneously to a set of destinations. In general, IP multicast provides a method of sending IP datagrams to a group of interested receivers in a single transmission. It is often employed for streaming media applications on the Internet and private networks.
IP multicast is a technique for one-to-many and many-to-many real-time communication over an IP infrastructure in a network. It scales to a larger receiver population by not requiring prior knowledge of who or how many receivers there are. Multicast uses network infrastructure efficiently by requiring the source to send a packet only once, even if it needs to be delivered to a large number of receivers. Special multicast nodes in the network (typically network switches and routers) take care of replicating the packet to reach multiple receivers such that messages are sent over each link of the network only once.
The most common low-level protocol to use multicast addressing is UDP. As discussed above, UDP is, by its nature, not reliable, i.e., messages may be lost or delivered out of order. Reliable multicast protocols such as Pragmatic General Multicast (PGM) have been developed to add loss detection and retransmission on top of IP multicast.
IP multicast communication often involves use of an IP multicast group address, a multicast distribution tree, and receiver driven tree creation. An IP multicast group address is used by source devices and the receivers to send and receive multicast messages. Source devices use the group address as the IP destination address in their data packets. Receiver devices use this group address to inform the network that they are interested in receiving packets sent to that group. For example, if some content is associated with group 239.1.1.1, the source device will send data packets destined to 239.1.1.1. Receiver devices for that content will inform the network that they are interested in receiving data packets sent to the group 239.1.1.1. The receiver device joins 239.1.1.1. Thus, the receiver devices are required to actively subscribe to a group, and are thus aware of their membership in the group. The protocol typically used by receiver devices to join a group in IP multicasting is called the Internet Group Management Protocol (IGMP).
With routing protocols based on shared trees, once the receiver devices join a particular IP multicast group, a multicast distribution tree is constructed for that group. The protocol most widely used for this is Protocol Independent Multicast (PIM). It sets up multicast distribution trees such that data packets from senders to a multicast group reach all receivers which have joined the group. For example, all data packets sent to the group 239.1.1.1 are received by receiver devices who joined 239.1.1.1. There are variations of PIM implementations: Sparse Mode (SM), Dense Mode (DM), Source Specific Mode (SSM) and Bidirectional Mode (Bidir, or Sparse-Dense Mode, SDM).
IP multicast creates state information per multicast distribution tree in the network. If a router is part of 1000 multicast trees, it has 1000 multicast routing and forwarding entries. On the other hand, a multicast router does not need to know how to reach all other multicast trees in the Internet. It only needs to know about multicast trees for which it has downstream receiver devices.
Thus, IP multicast typically requires specialized routers which understand the protocol and are able to replicate the packets at the appropriate time. So, although IP multicast can be effective in a private network, IP multicast is not practical for nodes in disparate networks to interact in real time over the Internet.
Conventionally, a given source device is required to be aware of each destination device to which it is communicating. For instance, in a videoconference between two devices, A and B, device A is aware of device B and vice-versa. In this situation, as the live video and audio stream from device A is communicated via IP packets that are directed from source device A to destination device B. Likewise, the live video and audio stream from device B is communicated via IP packets directed from source device B to destination device A.
As the number of devices participating in such a videoconference increases, each participating device must be aware of the other participating devices in conventional solutions. For instance, in a videoconference between three devices, A, B, and C, device A is aware of devices B and C, device B is aware of devices A and C, and device C is aware of devices A and B. In this situation, the live video and audio stream from device A is communicated via IP packets that are directed from source device A to destination device B and via IP packets that are directed from source A to destination device C. Thus, device A creates one stream of packets directed toward destination device B, and device A creates another stream of packets directed toward destination device C. Likewise, devices B and C may each create multiple streams of packets that are directed to the other destination devices participating in the live videoconference.